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Sections  of  the  Methodology 


1.  Forming  the  technical  architecture  concept 

2.  Dividing  electronics  into  domains 

3.  Setting  the  role  of  a  domain’s  technical  architecture 

4.  Structuring  a  domain’s  technical  architecture 

5.  Reducing  military  specifications 

6.  Reusing  hardware  and  software 

7.  Interoperating  weapon  and  C4I  systems 

8.  Coordinating  TAs  across  services/agencies 

9.  Integrating  TAs  across  domains 
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Strategic  Goals  for  Interoperabilty  of 
Weapon  System  Electronics 

To  sustain  superior  warfighting  effectiveness, 
DoD  is  pursuing  three  strategic  goals  for 
weapon  system  electronics 

•  Quick  insertion  of  new  technology 

•  Lower  life-cycle  costs  for  weapon  system 
electronics 

-  Hardware 

-  Software 

•  More  effective  joint  operations 

-  Among  weapon  systems 

-  Between  weapon  and  C4I  systems 
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Three  Tactics  Are  Key  To  Achieving 

DoD’s  Goals 


NDRI 


DoD’s  efforts  to  improve  interoperability  of 

_ weapon  system  electronics _  DoD’s  National 

Tactics  Strategic  Goals  Defense  Goal 
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JACG,  ARINC,  and  JTA  Can  Be 
Pathfinders  for  DoD’s  Three  Tactics 


NDRI 

1.  Reduce  Mil  Specs 

Industry  review  ^  SecDef 
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Extent  of  Experiences  in  Developing 
and  Using  the  Three  Tactics 


NDRI 


Phases  in  developing  and  using  new  architectures  and  new  practices 

Tactics  for 
improve¬ 
ment 

New  architectures  or  practices 

Apply  to  new  systems 

Identified  Developed  Implemented 

Development  Test  Operations 

1. 

Reduce 

Mil  Specs 

JACG 

Guide  JACG 

Specs  NQS 

GOA 

2. 

Reuse 

HW/SW 

ASOSA  JIAWG 

F-22  Comanche 

ARINC 

IFTE  MATE 

3. 

Weapon 

system 

C4I 

interfaces 

ATA 

arita  jta 

TAFIM 
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DoD  Policy  Memos  That  Stimulated 
Development  of  the  Three  Tactics 


-  Maintain  superior  effectiveness 
of  weapon  systems  by 

-  Improving  interoperation 

-  Increasing  ability  to 
incorporate  new  technologies 

-  Reduce  life  cycle  costs  of 
weapon  systems  by 

-  Increasing  use  of 

-  Performance  specifications 

-  Commercial  standards  and 

specifications _ 

-  Increasing  common  use  of 
hardware  and  software 


C4I 

initiatives 
— I - ' 

SecDef 
memo  — * 
6/94 


i 


I 


US  A&T 

memo 

11/94 
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USD  A&T  Memo  (11/94)  Calls  for  Open 
Systems  To  Improve  Interoperability 

•  "...directing  that  open  systems  specifications  and 
standards  (electrical,  mechanical,  thermal,  etc.)  be  used 
for  acquisition  of  weapon  systems  electronics  to  the 
greatest  extent  practical." 

•  "Open  system  specifications  and  standards  are 
concensus-based  public  or  non-proprietary 
specifications  and  standards  for  systems  and  interfaces 
of  hardware,  software,  tools,  and  architecture." 

•  "...these  systems  and  subsystems  shall  be  designed, 
developed,  and  constructed  as  open  systems  during  the 
acquisition  and  modification  process  to  reduce  life-cycle 
cost,  and  to  facilitate  effective  weapon  system  intra-  and 
interoperability." 

•  "I  hereby  establish  the  open  Systems  Joint  Task  Force  to 
sponsor  and  accelerate  the  adoption  of  open  systems  in 
electronices  included  in  weapon  systems  acquisitions." 
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Research  Hypothesis 


NDRI 


Our  research  hypothesis  has  two  parts 


*  The  technical  architecture  approach 
developed  by  the  C4I  community  can  be 
extended  to  weapon  system  electronics 


•  We  can  formulate  a  practical  method  for 
guiding  the  development  of  technical 
architectures  for  weapon  system  electronics 
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Approach  to  Designing  Methods  for 
Developing  Technical  Architectures 


Case  studies  of  efforts  to  improve  interoperability 


RAND 


Design  a 
methodology  for 
developing  Technical 
Architectures 


Methodology  for 
developing  Technical 
Architectures 


Domain/sub¬ 
domain 
definition 
for  weapon 
system 
electronics 


DoD 


DoD 


Process  for 
developing  a 
Technical 
Architecture 


Domain 
~  Technical  - 
Architecture 


Weapon  system 
development/ 
modification 
program 
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Strategy  for  Improving  Interoperability 
Aims  To  Evolve  a  Methodology 


Design  a  methodology  for  guiding  the  development 
of  Technical  Architectures  (Step  1) 

1 

Pilot  test  the  methodology  (Step  2) 

- > 

V 

▼ 

Institutionalize 

- >■ 

i 

Integrate  activities  across  the  Technical 
Architecture  Domains  (Step  4) 

- >- 
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The  Hypothesized  Role  of  a  Technical 
Architecture  for  WS  Electronics 

•  Divide  DoD’s  weapon  systems  electronics  into 
domains  and  subdomains 

*  For  each  weapon  system  electronics 
domain/subdomain 

-  Require  the  services  and  the  defense  agencies 
to  develop  a  set  of  rules  for  improving 
interoperability 

-  Define  the  rules  for  a  domain  as  the 
domain’s/subdomain’s  technical  architecture 

-  Use  the  technical  architectures  to  develop  and 
review  acquisition  /  modification  programs  at 
the  PEO,  Acq  Exec,  and  OSD  levels 
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A  Concept  for  Adapting  the  C4I 
Technical  Architecture  Approach 


Attainment  of 
Strategic  Goals  for 
Interoperability  of 
Weapon  System 
Electronics 


-  Quick  insertion  of 
new  technology 

-  Lower  life-cycle 
costs  for  weapon 
system  electronics 

-  More  effective  joint 
operations 

Sustain 

superior 

warfighting 

effectiveness 
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Extend  the  Operational  Architecture 
Concept  to  Weapon  Systems  Electronics 

Comparison  of  operational  architecture  concepts 

•  C4I  context 

-Focuses  on  C4I  information  exchanges 

-  Deals  with  information  management  systems 

•  Weapon  systems  electronics  context 

-  Focuses  on  many  types  of  interactions 

»  Information 
»  Jamming 
»  Support 

-  Deals  with  weapon  system  electronics 

»  Depicts  operational  context  for  each  weapon  system’s 
electronics  across  a  domain 


Volume  3.  Method.  FEB  1997 


Volume  3.  Method.  FEB  1997 


14  printed  01/27/2000  12:14 


Extend  the  Systems  Architecture  Concept 
to  Weapon  Systems  Electronics 

Comparison  of  systems  architecture  concepts 

•  C4I  context 

-  Focuses  on  C4I  information  management  systems 

-  Defines  the  C4I  systems  and  their  information 
interchange  requirements 

•  Individual  weapon  system,  electronics  context 

-  Focuses  on  HW  and  SW  for  a  weapon  system 

-  Defines  the  system  elements  and  their  arrangement 

•  Weapon  systems  electronics  domain  context 

-  Focuses  on  generic  style  of  HW  and  SW  for  a  domain 

-  Defines  the  system  elements  and  their  arrangement 
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Extend  the  Technical  Architecture 
Concept  to  Weapon  Systems  Electronics 

Comparison  of  technical  architecture  concepts 

•  C4I  context 

-  Focuses  on  technical  services,  interfaces,  and 
standards 

-  Considers  all  C4I 

*  Weapon  systems  electronics  context 

-  Focuses  on  identifying  a  sufficient  set  of  rules  to 
assure  opportunities  to  achieve  strategic  goals 

»  Technical 

»  Institutional  and  other  as  needed 

-  Considers  one  domain  of  weapon  systems 
electronics  at  a  time 
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Sections  of  the  Methodology 


1.  Forming  the  technical  architecture  concept 

2.  Dividing  electronics  into  domains 

3.  Setting  the  role  of  a  domain’s  technical  architecture 

4.  Structuring  a  domain’s  technical  architecture 

5.  Reducing  military  specifications 

6.  Reusing  hardware  and  software 

7.  Interoperating  weapon  and  C4I  systems 

8.  Coordinating  TAs  across  services/agencies 

9.  Integrating  TAs  across  domains 
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DoD  Has  Defined  Domains  for 
Weapon  System  Electronics 


•  Aviation 

•  Space  vehicles 

•  Maritime  vessels 

•  Automated  test  equipment 

•  Ground  vehicles 

•  Missile  defense  systems 

•  Missiles 

•  Munitions 

•  Soldier  systems 

•  Surveillance  /  reconnaissance 
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Types  of  Considerations  That  Should 
Influence  the  Definition  of  Domains 


•  Technical-economic 

-  Technical  distinctions  that  divide  electronics  into 
similiar  classes 

-  Economics  of  developing  and  supporting  technical 
architectures 

»  Evolution  with  changing  needs  and  technology 
»  Maturation  to  achieve  continuous  improvement 

•  Instituitional 

-  Cross  service  coordination  and  approval 

-  Incentives  versus  enforcement 

•  Integration 

-  Heirarchical  arrays  of  domains 

-  Flat  network  of  domains 
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The  Issue  of  Subdomains,  A 
Technical-Economic  Consideration 

•  Example  of  designing  hardware  for  too  broad  of  a  domain 

-  Development  costs  spread  over  large  production  run 

-  But,  production  costs  rise  due  to  too  broad  a  range  of 

»  Environments 
»  Packaging  requirements 

-  Each  produced  unit  needs  capabilities  for  extremely 
different  environmental  conditions  /  packaging 

•  Example  of  widely  different  environmental  needs 

-  Fighter  aircraft  and  helicopters 

»  High  altitude  and  high  g  loading  for  fighters 
»  Low  altitude  and  low  g  loading  for  helicopters 

-  Vibration: 

»  High  frequency,  low  amplitude  for  fighters 
»  Low  frequency,  large  amplitude  for  helicopters 
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Economic  Considerations  that  May 
Segment  Domains  into  Subdomains 


•  Environment  factors 

-  Dynamic  loads 

•  Vibrations 

•  Maximum  g  load 

-  Altitude 

•Packaging  factors 

-  Weight  criticality 

-  Volume  criticality 


-  Cleanliness 

-  Corrosion 

-  Moisture 
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Method  for  Subdividing  Weapon  System 
Electronics  into  Domains  (1  of  2) 

•  Environmental  assessment 

-  Assess  range  of  environmental  conditions 

-  Analyze  influence  on  design  and  costs  for  development, 
maturation,  production,  and  support 

•  Packaging  assessment  (hardware  and  software) 

-  Assess  range  of  packaging  needs 

-  Analyze  influence  on  design  and  costs  for  development, 
maturation,  production,  and  support 

•  Levels  assessment 

-  Assess  economics  of  reusing  hardware  and  software  at 
levels  of  potential  interest 

-  Consider  reuse  at  component  level,  subassembly  level,  etc. 

•  Analyze  economics  of  domain  breadth  considering 
environmental,  packaging,  and  levels  targeted  for  reuse 
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Method  for  Subdividing  Weapon  System 
Electronics  into  Domains  (2  of  2) 


NDRI 


Economic  tradeoff  analyses 

-  Environmental  factors 

-  Packaging  factors 

-  Potential  levels  for  reuse 


Institutional  tradeoff  analyses 

-  Opportunities  for  cross  Service  cooperation 

-  Methods  for  coordination 

•  Use  of  technical  architectures 

•  Role  of  OSD 

-  Cost  of  coordination  and  integration 


Domain/subdomain  structure  for  weapon  system  electronics 
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An  Example  Domain  Division  Based  on 
Environment,  Packaging  and  Level  Factors 

Aviation 

•  Fighter  and  attack  aircraft 

•  Strategic  bombers 

•  Transport  and  tanker  aircraft 

•  Large  electronic  platform  aircraft 

•  Attack/scout  helicopters 

•  Transport  helicopters 

•  Uumanned  aerial  vehicles 

Ground  vehicles 

•  Tanks 

•  Other  armored  vehicles 

•  Off-road  heavy  transport 

•  Off-road  light  transport 

•  On-road  heavy  transport 

•  On-road  light  transport 
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Sections  of  the  Methodology 


1.  Forming  the  technical  architecture  concept 

2.  Dividing  electronics  into  domains 

3.  Setting  the  role  of  a  domain’s  technical  architecture 

4.  Structuring  a  domain’s  technical  architecture 

5.  Reducing  military  specifications 

6.  Reusing  hardware  and  software 

7.  Interoperating  weapon  and  C4I  systems 

8.  Coordinating  TAs  across  services/agencies 

9.  Integrating  TAs  across  domains 
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Examples  of  Technical 
Architectures 


•  C4I  Joint  Technical  Architecture  (JTA) 

•  Army  Technical  Architecture  for  information 
systems  (ATA) 

•  Airborne  Reconnaisance  and  Intelligence 
Technical  Architecture  (ARITA) 

•  Joint  Integrated  Avionics  Working  Group 
(JIAWG) 

•  Modular  Automated  Test  Equipment  (MATE) 

•  ARINC  specifications  for  transport  aircraft 
avionics 
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Distinction  Between  Weapon 
Systems  and  Information  Systems 

NDRI 


Real  time  functional  control  systems 

-  Response  times  are  critical  to  mission  success  and  surviv 

-  Weapon  system  response  time  is  influenced  by 

-  Response  times  of  many  parts  of  the  system 

-  Ability  to  maintain  optimal  conrtrol  of  functions  in 

real  time 

-  Requires  models  to  represent  response  from 

alternative  control  inputs 

-  Must  model  the  performance  of  hardware  and 

software  in  the  operating  environment  in  real  ti 

-  Must  represent  hardware's  dynamic  reaction  to 
changing  environment 

-  Modeling  of  system  and  function  performance 

-  Ties  software  to  specific  hardware 

-  Makes  reuse  dependent  upon  hardware  and  software 


Provide  information,  but  do  not  control  functions  in  real  time 

-  Software  can  be  developed  independent  of  the  hardware 

-  Reuse  depends  upon  interface  specifications 
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The  Kalman  Filter  Example 
Illustrates  Modeling  Complexity 


Best  estimates  for  position  and  velocity 
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Distinctions  Between  Information 
Systems  and  Weapon  Systems 


Design  factor 

Information  System 
Development  Process 

Weapon  System 
Development  Process 

Objective 

Inform 

Real-time  control  of  the 
weapon  system  to  beat  the 
threat  and  survive 

Essentia! 

considerations 

Accuracy,  completeness, 
and  timeliness 

Minimize  weapon  system 
response  time 

Real-time  modeling  of 
weapon  system 
performance  in  the 
operating  environment 

Approach 

Populate  databases  and 
provide  user  friendly 
access 

Distributed  modeling  of 
system  elements 

Implications  for  a 
domain's  Technical 
Architecture 

Supports  a  high  degree 
of  modularity 

Allows  focus  on  software 

Modularity,  although 
desireable  and  sought,  is 
difficult  to  achieve 

Drives  architecture, 
software,  and  hardware 
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Technical  Architecture’s  Elements 
Depend  on  Type  of  System 


NDRI 


Comparison  of  an  Information  Systems  Technical  Architecture  with  the 
Necessary  Elements  of  a  Weapon  System  Technical  Architecture 


Elements  of  the  technical 
section  of  a  Technical 
Architecture 

Mechanization  rules 

Implementation  rules 

Information 

management 

systems 

Weapon 

systems 

Information 

managment 

systems 

Weapon 

systems 

Architectural  configuration 
("style")  for  the  domain 

X 

xxxx 

XX 

Software 

XXX 

XXX 

XX 

Hardware 

XXX 

XX 

Mechanization  rules  include  specification  of  a  system  architecture  and 
specification  of  interface  requirements. 


Implementation  rules  include  institutional  rules  and  resource  rules  that  govern 
joint  development  of  harware  and  software. 
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Challenges  To  Extending  Technical 
Architectures  To  Weapon  Systems 

•  Differences  that  may  influence  the  approach 
to  developing  technical  architectures  that  aim 
to  achieve  OSD's  interoperability  goal 

-Differences  between  information  systems 
and  weapon  systems 

-  Differences  among  weapon  systems 

•  Need  for  front-end  investment 

•  Problems  coming  up  in  the  world 

-Growing  emphasis  on  using  commercial 
products  in  military  systems 

-Speed  up  in  the  obsolesence  of  technology 
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Tradeoffs  Need  To  Be  Managed 

Across  Systems 


Cost 

avoidance 

attributable 

to 

change 


Extent  of  change  in  Mil  Specs  /  reuse  /  interoperation 


Cost  of 
implementing 

change 


Extent  of  change  in  Mil  Specs  /  reuse  /  interoperation 
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Potential  Types  of  Rules  for  a  Technical 
Architecture  for  a  Weapon  System 

•  Technical 

*  Institutional 

•  Development,  validation,  and  evolution 

*  Maintenance  and  maturation 

•  Resources 

*  Schedule 
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Sections  of  the  Methodology 


1.  Forming  the  technical  architecture  concept 

2.  Dividing  electronics  into  domains 

3.  Setting  the  role  of  a  domain’s  technical  architecture 

4.  Structuring  a  domain’s  technical  architecture 

5.  Reducing  military  specifications 

6.  Reusing  hardware  and  software 

7.  Interoperating  weapon  and  C4I  systems 

8.  Coordinating  TAs  across  services/agencies 

9.  Integrating  TAs  across  domains 
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Rules  and  Tactics  for  a  Weapon  System 
Electronics  Technical  Architecture 


Comprising  the  Reduce  Reuse  H/W  Improve 

Technical  Architecture  Mil  Specs  and  S/W  interoperation 

Technical 

Institutional 

Development,  valida¬ 
tion,  and  evolution _ 

Maintenance  and 

maturation _ 

Resources 

Schedule 
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Content  of  Technical  Architecture  Needs 
To  Focus  on  a  Domain’s  Opportunities 


Types  of  Rules  Tactics  for  Improvement 

Comprising  the  Reduce  Reuse  H/W  Improve 

Technical  Architecture  Mil  Specs  and  S/W  interoperation 

Technical 

Institutional 

Development,  valida¬ 
tion,  and  evolution 

Maintenance  and 
maturation 

Resources 
Schedule 


xxxx 

XX 

xxxx 

xxxx 
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Development  and  Integration  of 
Domain  Technical  Architectures 


Methods  for  developing 
technical  architectures 


Methods  for  integrating 
technical  architectures 


Weapon 

system 

electronics 

domains 


Reduce  Mil 
Specs 
(Section  5) 

Across 

Domain 

services 
(Section  8) 

Reuse 

technical 

(Section  6) 

architectures 

Across 

Interoperate 
(Section  7) 

domains 
(Section  9) 
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An  Illustrative  Structure  for 
Organizing  a  Technical  Architecture 


TA  Section  1.  Technical 

TA  Section  2.  Institutional 

TA  Section  3.  Development,  validation,  and 

evolution 

TA  Section  4.  Maintenance  and  maturation 
TA  Section  5.  Resources 
TA  Section  6.  Schedule 
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Technical  Section  of  a  Technical 
Architecture  for  WS  Electronics  (1  of  4) 


1.1  Operational  architectures 

1.1.1  *  Domain  Operational  Architecture 

-  Functions  to  be  provided  by  the  domain’s 
electronics,  and  their  interdependencies 

1.1.2  *  Domain  Software  Operational  Architecture 

-  Functions  to  be  provided  by  the  domain’s 
software,  and  their  interdependencies 

1.1.3  •  Domain  Hardware  Operational  Architecture 

-  Functions  to  be  provided  by  the  domain’s 
hardware,  and  their  interdependencies 
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Technical  Section  of  a  Technical 
Architecture  for  WS  Electronics  (2  of  4) 

1-2  System  architectures 

1.2.1  .  Domain  system  architecture(s) 

-  Equipment  architectural  style(s)  for  the  domain:  the 
general  principles  for  arranging  the  electronics 
hardware  and  software  for  the  domain 

1-2-2  •  Domain  software  system  architecture(s) 

-  Software  architectural  style(s)  for  the  domain:  the 
general  principles  for  arranging  the  software 

1.2.3  •  Domain  hardware  system  architecture(s) 

-  Hardware  architectural  style(s)  for  the  domain:  the 
general  principles  for  arranging  the  hardware 
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Technical  Section  of  a  Technical 
Architecture  for  WS  Electronics  (3  of  4) 

■!-3  Interface  requirements 

1.3.1  •  Domain  interface  requirements 

-  Principles,  practices,  and  standards  to  be  adhered 
to  in  the  design  of  system  harware  and  software 
elements  compliant  with  the  architectural  style 

t.3.2  ,  Domain  software  interface  requirements 

-  Principles,  practices,  and  standards  to  be  adhered 
to  in  the  design  of  system  software  compliant  with 
the  architectural  style 

1.3.3  •  Domain  hardware  interface  requirements 

-  Principles,  practices,  and  standards  to  be  adhered 
to  in  the  design  of  system  hardware  compliant  with 
the  architectural  style 
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Technical  Section  of  a  Technical 
Architecture  for  WS  Electronics  (4  of  4) 

■\a  .  Technical  reference  models  defining  the 
entities  addressed  by  the  technical 
architecture 

1.5  •  Additional  standards  that  will  be  adhered  to 
within  the  domain 
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Institutional  Section  of  a  Technical 

Architecture  (1  of  2) 

2.1  *  Functions  of  institutions  that  are  required  to 

-  Develop,  validate,  evolve,  maintain,  and  mature  the 
technical  architecture 

»  Requirements  for  organizations  and  weapon  system 
programs  to  perform  life-cycle  management  tradeoffs 

•  For  a  weapon  system 

•  Across  weapon  systems 

•  Across  services 

-  Apply,  incentivize  and  enforce  the  technical 
architecture 

2.2  •  Division  of  responsibility  and  authority 

across  institutions  for  providing  the  required 
functions 
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Institutional  Section  of  a  Technical 

Architecture  (2  of  2) 

■  NDRI 

2.3  *  Interface  requirements  for  participating 

institutions 

-  Guidelines  for  intra-domain  coordination  across 
organizations  and  programs 

-  Guidelines  for  inter-domain  coordination 

»  Technical  architectures 
»  Organizations  and  programs 

-  Guidelines  for  incentives  and  enforcement 

2.4  •  Current  documents  governing  the 

participation  of  participating  institutions 

-  Guidance  from  higher  authorities 

-  Agreements  among  participating  institutions 
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Development,  Validation,  and  Evolution 
Section  of  a  Technical  Architecture 


3.1  .  Processes 

-  Technical  processes  involved  in  the  development, 
validation,  and  evolution  of  the  technical 
architecture 

»  These  might  include  tests  and  other  methods  that 
address  the  technical  content  of  the  technical 
architecture 

-  Milestones:  approval  by  Services,  defense  agencies 
and  OSD 

3.2  *  Roles  and  duties 

-  OSD:  funding  and  oversight 

-  Participating  services  and  defense  agencies 
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Maintenance  and  Maturation 
Section  of  a  Technical  Architecture 

i  •  Processes 
-Activities 

»  Assessment 

»  Housekeeping  and  monitoring 
»  Research  and  refinement 

-Milestones 
.2  •  Roles  and  duties 

-OSD 

-  Participating  services  and  defense 
agencies 

-Commercial  R&D,  standards,  etc. 
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Resource  Section  of  a  Technical 

Architecture 


NDRI 


5-i  •  Requirements  on  the  nature  and  extent  of  life- 

cycle  management  tradeoffs  for  a  weapon 
system 

-  Across  weapon  systems 

-  Across  services 

5.2  *  Approach  to  obtaining  and  managing 

resources  required  for  front-end  investments 
that  enable  development,  validation, 
evolution,  maintenance,  maturation, 
implementation  and  enforcement  of  technical 
architectures 
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Schedule  Section  of  a  Technical 

Architecture 

61  •  Initial  establishment  of  the  technical 

architecture 

6.2  *  Subsequent  maintenance  and  evolution 

6.3  •  Resolution  of  schedule  conflicts 
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Sections  of  the  Methodology 


1.  Forming  the  technical  architecture  concept 

2.  Dividing  electronics  into  domains 

3.  Setting  the  role  of  a  domain’s  technical  architecture 

4.  Structuring  a  domain’s  technical  architecture 

5.  Reducing  military  specifications 

6.  Reusing  hardware  and  software 

7.  Interoperating  weapon  and  C4I  systems 

8.  Coordinating  TAs  across  services/agencies 

9.  Integrating  TAs  across  domains 
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This  Section  Addresses  Methods  for 
Reducing  Military  Specifications 


NDRI 


DoD’s  efforts  to  improve  interoperability  of 
_ weapon  system  electronics _ 

Tactics  Strategic  Goals 


1 .  Reduce  use  of 
Mil  Specs 


Insert  new 
technology 
quickly  across 
weapon  systems 

Reduce  life 
cycle  costs  of 
weapon  system 
electronics 

Improve 
effectiveness  of 
joint  operations 


DoD’s  National 
Defense  Goal 


Sustain 

superior 

warfighting 

effectiveness 
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Prospective  Method  for  Reducing 
Military  Specifications 

*  Research  of  relevant  experience 

*  Prospective  technical  approach 

*  The  JACG  business  process  model 

*  Adapting  the  business  process  model 
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Overview  of  the  Mil  Spec  Problem 


•  Role  of  specifications 

-  Communicate  buyers  needs 

-  Basis  for  factory  acceptance 

-  Basis  for  system  and  qualification  testing 

•  Whats  wrong  with  Mil-Specs 

-  Control  too  much  “how  to”  including  materials  and 
processes 

-  Seldom  updated 

-  Are  frequently  user  specific 

•  What  can  be  used? 

-  Commercial  specs 

-  Military  general  performance  specs 

-  Limited  application  specific  performance  specs 

Note:  A  performance  spec  requires  a  performance  attribute,  it  does  not 
specify  how  to  achieve  that  attribute  (or  necessarily  how  to  test  it). 
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Case  Studies  of  Activities  Focused 
Mainly  on  Reduction  of  Mil  Specs 

NDRI 


•  Joint  Aeronautical  Commanders  Group  (JACG) 

-  Aeronautical  Engineering  Board  (AEB) 

-  Avionics  Engineering  Sub  Board  (AESB) 

•  Generic  Open  Architecture  (GOA) 


Volume  3.  Method.  FEB  1997 


Volume  3.  Method.  FEB  1997 


53  printed  01/27/2000  12:14 


Prospective  Method  for  Reducing 
Military  Specifications 

*  Research  of  relevant  experience 

*  Prospective  technical  approach 

*  The  JACG  business  process  model 

*  Adapting  the  business  process  model 
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NDRI 


Reducing  Mil  Specs  Increases 
Acquisition  Flexibility 


Weapon 

system 

specifications 


Observe 
design  choices 
and 

conformance 
with  standards 
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Observe 
production 
process  and 
conformance  with 
standards 


f 


Observe 

performance  and 
conformance  with 
performance 
specifications 

1 


When  necessary,  seek  remedy  for  nonconformance 
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A  Technical  Reference  Model  for 

the  JACG 


NDRI 


Common  Use,  Military  Unique  Specs  &  Stds  Needed  to  Develop  & 


Fii 
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Requirements  for  the  Methods  Used 
To  Reduce  Mil  Specs  (1  of  2) 

•  Alternatives  to  Mil  Specs 

-  Commercial  specifications 

-  Performance  based  specifications 

•  Analyses  of  alternatives  must  consider 

-  Life  cycle  costs 

-  Full  accounting  of  support  costs 

•  When  eliminating  Mil  Specs,  processes  must 
be  established  to  assure  adequate 

-  Insertion  of  design  and  process  requirements  in 
technical  data  packages 

-  Flowdown  of  specs  from  level  to  level 

•  New  specifications  must  reflect  customer 
needs  formerly  communicated  by  Mil-Specs 
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Requirements  for  the  Methods  Used 
To  Reduce  Mil  Specs  (2  of  2) 


*  Contractors  must  be  given  flexibility,  while 
the  government  maintains 

-Minimum  essential  controls 

-Enough  technical  data  package  control  to 
assure  openness  where  cost  effective 

•  Contracts  must  provide 

-  Incentives  to  reduce  Mil  Specs 
-Mechanism  that  assures  needed  openess 
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Principles  for  use  of  Non  Government 
Standards  Developed  by  the  JACG 

•  Complete  technical  data  package  is  necessary  at  all 
levels 

•  Technical  requirements  flow  down  to  the  lowest  level 

•  Contracts  written  to  encourage  prime  use  of 
performance  based  standards 

•  The  build  and  support  packages  must  have  a  common 
technical  basis 

•  Implementation  flexibility  is  critical 

•  The  essential  performance  attributes  of  the  old  Mil 
Specs  need  to  be  in  the  appropriate  specifications 

•  Control  of  portions  of  each  level’s  technical  data 
package  driven  by  program/technical  risk 

-  Contractors  of  demonstrated  capability  given 
greater  authority/responsibility 
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Technical  Data  Package  (1  of  2) 


•  Allocated  functional  requirement 

•  Acceptance  criteria 

•  Interface  control  document 

•  Software  documentation 

-  Language  and/or  operating  system  requirements 

-  Functional  requirements 

-  Interface  requirements 

-  Verification  and  acceptance  requirements 

-  Documentation  requirements 
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Technical  Data  Package  (2  of  2) 


NDRI 


•  Drawings  with  tolerances 

-  Material  Standards 

-  Process  Standards 

-  Physical  configuration  of  item 

•  Bill  of  Material 

-  Materials  including  components  or  assemblies 

-  Material  Standards 

-  Process  qualification  standards  for  supplier 

-  Acceptance  criteria 
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Flow  Down  of  Design  Specs  and 
Buidup  of  Acceptance  Criteria 


■  NDRI 
System  ( 
performance 
specs  ^ 
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ICD  -  Interface  Control  Document 
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Prime  Contractor  Controls  Flow  Down  of 
Performance  Specifications 


■  NDRI 

-  Systems 

Governmen  ->»  Requirement  — * 
-  Document  (SRD) 


System  Specification  (with  Government) 

-  Performance  Requirements 

-  Verification  Requirements 


i  m  roi  psiHii  s  WMimrai  iraii  ki 


Prime  Item  Development  Spec  (with  Gov  or  Prime 
Prime  Item  Product  Design  Spec 
•Prime  Item  Interface  Document 
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Subsystem  Development  Spec  (with  Prime) 
Subsystem  Product  Design  Spec 
•Subsystem  Interface  Document 
•Subsystem  Acceptance  Criteria 
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Component  Development  Spec  (with  Sub) 
Component  Product  Design  Spec 
•Component  Interface  Document 
•Component  Acceptance  Criteria 
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Prospective  Method  for  Reducing 
Military  Specifications 

*  Research  of  relevant  experience 

*  Prospective  technical  approach 

*  The  JACG  business  process  model 

*  Adapting  the  business  process  model 
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A  Business  Process  for  Developing  a 
Performance-Based  Specification  System 


NDRI 
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Institutional  Factors  Addressed  by  the 
JACG  for  Performance  Based  Specs 


Minimize  government's  use  of  existing  military 
specifications  and  standards  and  non-goverenment 
documents  that  are  not  performance  based 

Performance  based  acquisition 
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Prospective  Method  for  Reducing 
Military  Specifications 

*  Research  of  relevant  experience 

*  Prospective  technical  approach 

*  The  JACG  business  process  model 

*  Adapting  the  business  process  model 
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Issues  That  Need  Further  Attention 


•  Depending  upon  how  it  is  done,  reducing  Mil  Specs 
may  complicate  realization 
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Suggested  Adaptations  to  the 
Business  Process  Model 

1.  Provide  for  the  development  of  criteria  that 
program  offices  and  prime  contractors  could 
use  to  evaluate  the  net  value  of  not  using 
military  specifications  in  specific  areas 

2.  Obtain  outsource  technical  assistance 

-  Develop  criteria  for  replacing  Mil  Specs 

-  Evaluate  applications  of  the  criteria  and  refine  as 
neeeded 

3.  Develop  principles  to  be  followed  by  prime 
contractors  in  interface  development 

4.  Outsource  technical 
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Why  Outside  Technical  Assistance? 


NDRI 


•  Technical  expertise 


•  Provide  “honest  broker” 


•  Development  continuing  relationships 


•  Avoid  “procedure  based”  approach  that 
would  repeat  the  Military  Specification 
problems 
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Sections  of  the  Methodology 


1.  Forming  the  technical  architecture  concept 

2.  Dividing  electronics  into  domains 

3.  Setting  the  role  of  a  domain’s  technical  architecture 

4.  Structuring  a  domain’s  technical  architecture 

5.  Reducing  military  specifications 

6.  Reusing  hardware  and  software 

7.  Interoperating  weapon  and  C4I  systems 

8.  Coordinating  TAs  across  services/agencies 

9.  Integrating  TAs  across  domains 
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This  Section  Addresses  Methods  for 
Increasing  Reuse  of  Electronics 


NDRI 


DoD’s  efforts  to  improve  interoperability  of 
_ weapon  system  electronics _ 

Tactics  Strategic  Goals 


Insert  new 
technology 
quickly  across 
weapon  systems 

Reduce  life 
cycle  costs  of 
weapon  system 
electronics 

Improve 
effectiveness  of 
joint  operations 


DoD’s  National 
Defense  Goal 


Sustain 

superior 

warfighting 

effectiveness 
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NDRI 


Prospective  Method  for  Reusing 
Hardware  and  Software 


*  Research  of  relevant  experience 

-  Reuse  goals  and  relevant  experiences 

-  Case  studies  of  relevant  experiences 

-  Experience  of  the  JIAWG 

-  Experience  of  ARINC 

*  Prospective  technical  approach 

*  The  ARINC  business  process  model 

*  Adapting  the  business  process  model 
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NDRI 


Case-Study  Objectives  for 
Experiences  Relevant  To  Reuse 


*  Formulate  a  generic  methodology  for 
developing  technical  architectures  aimed  at 
increasing  reuse  of 

-  Commercial  hardware  and  software 

-Defense-peculiar  hardware  and  software 

*  Explore  how  to  build  upon  the  JACG,  AESB, 
and  GOA  work  to  further  the  reuse  of  weapon 
system  electronics 

*  Explore  potentially  relevant  commercial 
experience  (ARINC) 
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Case  Studies  of  Activities  with  a 
Strong  Focus  on  Reuse 

*  Aviation  electronics 

-  Joint  Integrated  Avionics  Working  Group  (JIAWG) 

-  ARINC  activities 

-  Army  System  of  Systems  Architecture  (ASOSA) 

-  Generic  Open  Architecture  for  AESB 

•  Automatic  test  equipment 

-  Modular  Automatic  Test  Equipment  Program 

-  U.S. 
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Case  Study  Initial  Findings  for 

Reuse  (1  of  2) 

NDRI 


*  To  reduce  life  cycle  costs  and  reduce  the  time 
to  insert  technology  by  reusing  hardware  and 
software,  a  technical  architecture  must 

-Specify  a  common  architectural 
arrangement  for  the  hardware  and  software 
to  be  used  in  common  within  the  domain 

»  This  domain  system  architecture  is  part  of  the 
technical  architecture 

-Specify  interfaces  for  common  software 

-Specify  interfaces  (form,  fit,  and  function) 
and  permissible  operating  environments 
for  common  hardware 
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Case  Study  Initial  Findings  for 

Reuse  (2  of  2) 


*  Application  of  such  a  technical  architecture 
may  require  a  front-end  investment 

-Trade  studies  are  required  to  assess  the 
net  worth  of  alternative  approaches  to  the 
domain’s  system  architecture  that  is 
included  in  the  technical  architecture 

*  Technical  architectures  may  differ  widely 
across  domains 

-Differences  between  information  systems 
and  weapon  systems  illustrates  the 
reasons 
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Value  of  Common  Architectures 
Depends  on  the  Situation 

*  Common  architectures  provide  flexibility 

-  But,  flexibility  costs 

-  May  or  may  not  be  worthwhile  depending  upon 

»  Extent  of  flexibility 
»  Situation 

*  Services  need  a  tradeoff  process 

*  Experience  is  mixed 

-  JIAWG:  an  initial  effort 

-  ARINC:  a  mature  approach 
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The  JIAWG  Common  Architecture 


NDRI 

Modern  Avionics  Architecture 
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Need  for  Tradeoff  Analyses 


NDRI 


Architecture's  flexibility  Architecture's  flexibility 
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Prospective  Method  for  Reusing 
Hardware  and  Software 


*  Research  of  relevant  experience 

-  Reuse  goals  and  relevant  experiences 

-  Case  studies  of  relevant  experiences 

-  Experience  of  the  JIAWG 

-  Experience  of  ARINC 

*  Prospective  technical  approach 

*  The  ARINC  business  process  model 

*  Adapting  the  business  process  model 
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Experience  of  the  Joint  Integrated 
Avionics  Working  Group  (1  of  2) 

Purpose:  use  common  line  replaceable  modules 
across  Services 

•  Make  it  easier  to  mature  and  support  avionics 
Dissimilar 
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Experience  of  the  Joint  Integrated 
Avionics  Working  Group  (2  of  2) 

•  Attempted  to  standardize  across  services 

-  Standard  line  replaceable  modules  (LRMs) 

-  Competition  and  support 

-  Protocol  issues 

-  Environmental  control 

-  Common  architecture  -  down  to  common 
connectors  for  the  operating  environment 

•  Impediment:  diverse  environment 

-  Different  vibration  spectra  led  to  different  designs 

•  Remaining  issues 

-  Life-cycle  management  tradeoffs 

»  Technology  insertion 
»  Effectiveness  improvement 
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Prospective  Method  for  Reusing 
Hardware  and  Software 


*  Research  of  relevant  experience 

-  Reuse  goals  and  relevant  experiences 

-  Case  studies  of  relevant  experiences 

-  Experience  of  the  JIAWG _ 

-  Experience  of  ARINC 

*  Prospective  technical  approach 

*  The  ARINC  business  process  model 

*  Adapting  the  business  process  model 
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ARINC 


NDRI 

*  Founded  in  1929  as  wholly 
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An  Overview  of  ARINC 


NDRI 

•  Controlled  by  the  Airlines 

•  Offers 
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Significance 


*  Provides  a  commercial  industry  process  model  for 
developing  “open”  specifications  for  common  avionics 
equipment  with  reuse  and  technology  benefits. 

*  Experience  in  “brokering”  a  specification  development 
process  including  manufacturers  and  buyers 

*  Provides  an  example  of  a  well  controlled  process  that 
does  not  use  the  rigid  “military  specification”  approach 

*  Has  both  commercial  industry  and  military  support 
experience 

*  Is  consistent  with  the  “New  Commercial  Ways  of  Doing 
Business” 
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Driving  Forces  in  Industry  Are 
Lacking  in  the  DoD  Environment 


•  Airlines  want  low  cost  equipment 

•  Airlines  have  a  clear  economic  model  of  their 
cost  structure  and  a  long  term  interest  in  it 

•  Aircraft  manufacturers  want  low  avionics  and 
maintenance  costs 

•  Avionics  manufacturers  want  access  to  as 
large  a  market  as  possible 
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Prospective  Method  for  Reusing 
Hardware  and  Software 

*  Research  of  relevant  experience 

*  Prospective  technical  approach 

*  The  ARINC  business  process  model 

*  Adapting  the  business  process  model 
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Approach  for  Developing  a  Technical 
Architecture  for  Reuse  (1  of  5) 

•  Define  the  weapon  systems  included  in  the 
domain  addressed  by  the  technical 
architecure 

•  Define 

-  Missions  performed  by  the  weapon 
systems  in  the  domain 

-Situations  and  conditions  under  which  the 
missions  must  be  performed 

»  Time  varying  and  dynamic  through 
mission  phases 

»  Varying  across  missions 
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Approach  for  Developing  a  Technical 
Architecture  for  Reuse  (2  of  5) 

•  Define  the  functions  that  have  to  be  created, 
such  as 

-Communication 

-  Navigation 

-Situation  awareness  (visual,  radar,  infrared) 
-Target  acquisition 

-  Management  of  stored  armament 
-Initialization  of  armament 
-Steering  of  armament 

-Housekeeping  (e.g.,  controlling  the  motion  of 
the  weapon  system  platform) 
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Approach  for  Developing  a  Technical 
Architecture  for  Reuse  (3  of  6) 

*  Lay  out  alternative  architectures  to  carry  out 
the  functions  effectively,  while  also  providing 

-  Necessary  fault  isolation 

-An  opportunity  to  realize  the  strategic 
goal(s)  most  needing  increased  emphasis 
in  this  domain 

»  Partition  the  system  to  facilitate 
attainment,  while  satisfying  other 
necessary  requirements 

•  Analyze  the  alternative  architectures  (in  terms 
of  technical,  institutional,  resource,  and 
schedule  aspects) 
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Approach  for  Developing  a  Technical 
Architecture  for  Reuse  (4  of  5) 


•  Select  the  architecture(s)  for  the  domain 

•  Lay  out  alternative  designs  for  the  interfaces  to 
mechanize  the  architecture 

•  Analyze  the  alternatives  in  terms  of  technical, 
institutional,  resource,  and  schedule  aspects 

•  Select  the  most  appropriate  interface  designs 

-As  appropriate,  select  commercial  interface 
specifications 

-As  necessary,  develop  new  interface 
specifications 
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Approach  for  Developing  a  Technical 
Architecture  for  Reuse  (5  of  5) 


*  Complete  the  technical  architecture  in  terms 
of  the  sections  and  subsections  defined  in 
Section  4  of  the  methodology: 

-Section  1.  Technical 

-Section  2.  Institutional 


»  Including  incentives  and  enforcement 


-Section  3. 
evolution 

-Section  4. 

-Section  5. 

-Section  6. 


Development,  validation,  and 

Maintenance  and  maturation 

Resources 

Schedule 
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Guidelines  for  Developing  and  Using  a 
TA  To  Increase  Reuse  (1  of  2) 

•  Have  clear,  limited  objectives 

*  Use  incentives  not  mandates 
Have  clear  demarcations 
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Guidelines  for  Developing  and  Using  a 
TA  To  Increase  Reuse  (2  of  2) 

*  Scheduled  Technical  Milestones 

-  Technical  event  to  complete  tightly  defined 

-  Reasonable  but  firm  schedule 

-  Responsibility  of  program  manager 

*  Conduct  an  extensive,  continuing  test 
program 

-  Any  development  is  a  learning  process 

-  Learning  takes  place  through  test  failures 

-  Funded  extensive  test  program 
»  -  Saves  money 

»  -  Saves  time 
»  -  Gives  high  quality 
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Prospective  Method  for  Reusing 
Hardware  and  Software 

*  Research  of  relevant  experience 

*  Prospective  technical  approach 

*  The  AR1NC  business  process  model 

-  Development  of  specifications 

»  The  ARINC  process 
»  Process  steps 
»  Process  characteristics 

-  Products 
-Schedule 

*  Adapting  the  business  process  model 
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Participants  in  The  ARINC  Process 
for  Developing  Specifications 


NDRI 
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Policies  for  the  ARINC  Specification 
Development  Process 


•  Established  roles  for  participants 

•  Chaired  by  an  airline 

•  Formatted  document  structure 

•  Formatted  time  to  develop 

•  Does  not  follow  “rules”  but  has  established 
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Roles  and  Duties  of  the  Participants 


NDRI 


1  -  Specification  Committee  members  have 

direct  interest 

2  -  Use  of  “tight”  but  unwritten  document  and 

schedule  formats 


3  -  Specification  Committee  members  can 

commit  their  organizations 

4  -  Analysis  of  operating  savings  required 

before  specification  work 

5  -  Compliance  relies  on  economics  of  process 

6  -  ARINC  takes  role  as  broker,  not  developer 

7  -  Economics  enforce  “long  term”  view 
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Steps  in  the  ARINC  Process  for 
Developing  Specification 


1.  The  proposal  -  specification  is  suggested 

2.  The  work  program  -  each  fall  year’s  work  is 
planned 

3.  Committee  formed  -  chairman  and  members 
of  specification  committee  selected 

4.  “Strawman”  specification  developed  - 
circulated  with  intervening  meetings 

5.  Specification  adopted  -  2/3  vote  of  Airline 
Electronics  Committee 

6.  Final  review  period  -  thirty  day  comment 
period  for  any  ARINC  member,  either 
resolved,  or  passed  by  new  2/3  vote 
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NDRI 


Prospective  Method  for  Reusing 
Hardware  and  Software 


•  Research  of  relevant  experience 

•  Prospective  technical  approach 

•  The  ARINC  business  process  model 

-  Development  of  specifications 

»  The  ARINC  process 
»  Process  steps 

_ »  Process  characteristics _ 

-  Products _ 

-Schedule 

•  Adapting  the  business  process  model 
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Types  of  ARINC  Documents 


NDRI 


1  -  Characteristics  Documents  -  Specify  form, 

fit,  and  function 


2  -  Specifications  -  Give  interface  specifications 

and  system  overview 


3  -  Reports  -  Give  technical  guidance  for 

dealing  with  generic  problems: 
example,  environmental  guidelines 
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Vertical  Slice  of  an  ARINC  Specification 
“Tree”  Showing  the  Flow  Down  of  Specs 


Specification  600-10 


Air  Transport  Avionics 
Equipment  Interfaces 


Specification  650 


Characteristic  716-9 


Integrated  Modular  Avionics 
Packaging  and  Interfaces 

Aviation  Satellite  Communication 
System,  Part  1  Aircraft  Installation 
Provisions 
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Some  of  the  ARINC  Reports  Associated  with 

the  Specification  “Tree” 

Environmental  Design  Guidelines 
for  Integrated  Modular  Packaging 
and  Interfaces 

_  Guidance  for  Avionics 

Software  Development 

_  Design  Guidance  for 

Onboard  Maintenance  System 

_  CNS/ATM  Avionics,  Functional  Allocation 

and  Recommended  Architectures 

—  Test  Equipment  Guidance  (TEG) 

_  Industry  Guide  for  Test  Program  Set  (TPS) 

Quality  Management 


Report  652 
Report  624-1 
Report  660 
Report  602A 
Report  625 
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Prospective  Method  for  Reusing 
Hardware  and  Software 

*  Research  of  relevant  experience 

*  Prospective  technical  approach 

*  The  ARINC  business  process  model 

-  Development  of  specifications 

»  The  ARINC  process 
»  Process  steps 
»  Process  characteristics 

-  Products 
-Schedule 


*  Adapting  the  business  process  model 
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Time  Frame  for  Documents 

•  Nominal  -  Shoot  for  one  year 

•  Simple  may  take  3  months,  example:  Flight  Recorder 

•  Complex  can  be  expected  to  be  longer: 

Modular  Avionics  took  6-7  years 


Volume  3.  Method.  FEB  1997 


Volume  3.  Method.  FEB  1997 


107  printed  01/27/2000  12:14 


Prospective  Method  for  Reusing 
Hardware  and  Software 

*  Research  of  relevant  experience 

*  Prospective  technical  approach 

*  The  ARINC  business  process  model 

*  Adapting  the  business  process  model 
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What  Should  the  DOD  Counterpart 

to  ARINC  Be? 


NDRI 


Airlines 


'iMrline^' 
Equipment 
Industry  . 


\  ARINC  / 

— /  Specification 
\  \^AixhitecUire^/y/ 

Significant  Economic  Benefits 


Services 


Defense 

Equipment 

•Jndustrv^- 


Technical 

Architecture 


^^^Mrcmieciure^y  / 

Interoperability,  Lower  Cost, 


[•j  u  w*  rawnr.!.  k'Ai  iy  y  n  u. 
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Challenges  in  Applying  the  ARINC 
Approach  to  Defense  Industry 

NDRI 

•  More  Product  Lines 

•  Broader  and  Many  Times  More  Diverse  Environment 

•  More  Technologically  Dynamic  and  Diverse 

•  Broader  Scope 

•  More  Complex  Systems 
»  MORE  POLITICS 

»  MUCH  HARDER  TO  OBSERVE  BOTTOM  LINE 
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DoD  Actions  Needed 


NDRI 

1.  Identify  high  level  “sponsor 
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Sections  of  the  Methodology 


1.  Forming  the  technical  architecture  concept 

2.  Dividing  electronics  into  domains 

3.  Setting  the  role  of  a  domain’s  technical  architecture 

4.  Structuring  a  domain’s  technical  architecture 

5.  Reducing  military  specifications 

6.  Reusing  hardware  and  software 

7.  Interoperating  weapon  and  C4I  systems 

8.  Coordinating  TAs  across  services/agencies 

9.  Integrating  TAs  across  domains 
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This  Section  Addresses  Methods  for 
Improving  Interoperation 


NDRI 


DoD’s  efforts  to  improve  interoperability  of 
_ weapon  system  electronics _ 

Tactics  Strategic  Goals 


Insert  new 
technology 
quickly  across 
weapon  systems 

Reduce  life 
cycle  costs  of 
weapon  system 
electronics 

Improve 
effectiveness  of 
joint  operations 


DoD’s  National 
Defense  Goal 


Sustain 

superior 

warfighting 

effectiveness 
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Prospective  Method  for  Improving 

Interoperation 


*  Research  of  relevant  experience 

-  Overview  of  the  interoperation  problem  | 

-  Case  studies  of  relevant  experiences 

-  Experience  of  the  ATA 

-  Experience  of  the  JTA 

*  Prospective  technical  architecture 

*  The  JTA  business  process  model 

*  Adapting  the  business  process  model 
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The  Interoperation  Problem  for 
Weapon  Systems*  (1  of  3) 

•  Stovepiping  of  systems 

-  Few  aircraft  communicate  with  ground  units,  e.g. 

-  Starts  with  requirements  and  includes  budgeting, 
acquisition,  and  training 

•  Architectures  for  C2 

-  Separate  for  each  Service 

-  No  apparent  way  to  integrate 

•  Terminology 

-  Lack  of  shared  understanding,  misuse,  and 
insufficient  precision 

-  Widespread  use  of  “architectures”  without  rigor 
needed  to  convey  their  meaning  consistently 

*Source:  C4ISR  Task  Force  (1996),  and  SAB  (1996) 
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The  Interoperation  Problem  for 
Weapon  Systems*  (2  of  3) 


•  Communication  connectivity 

-  Incomplete 

-  Voice  oriented 

-  Doesn’t  support  sharing  of  sensor  data 

•  Missed  opportunities 

-  C3  capabilities  have  not  kept  pace  with  weapon  and 
sensor  system  technologies 

•  Proliferation  of  different  C3  systems  and 
subsystems  within  weapon  systems 

-  Inflates  development  and  support  costs 

-  Limits  incorporation  of  new  C3  capabilities  due  to 
prohibitive  modification  costs 

*Source:  C4ISR  Task  Force  (1996),  and  SAB  (1996) 
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The  Interoperation  Problem  for 
Weapon  Systems*  (3  of  3) 

•  Current  system  for  developing  and  fielding 
command  and  control  systems 

-  “Inadequate” 

-  “Unacceptable” 

•  Requirements  for  weapon  system  C3 
capabilities 

-  No  standardized,  mission-oriented  architecture  to 
requirements  definition 

•  Joint  Staff  lacks  abilities  to 

-  Assure  requirements  are  understood,  integrated, 
and  non-duplicative  across  the  DoD 

-  Ascertain  systems  are  aligned  with  joint  needs 
‘Source:  C4ISR  Task  Force  (1996),  and  SAB  (1996) 
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Prospective  Method  for  Improving 

Interoperation 


*  Research  of  relevant  experience 

-  Overview  of  the  interoperation  problem 

-  Case  studies  of  relevant  experiences 

-  Experience  of  the  ATA 

-  Experience  of  the  JTA 

*  Prospective  technical  architecture 

*  The  JTA  business  process  model 

*  Adapting  the  business  process  model 


Volume  3.  Method.  FEB  1997 


Volume  3.  Method.  FEB  1997 


118  printed  01/27/2000  12:14 


Case-Study  Objectives  for  Experiences 
Relevant  To  Improving  Interoperation 


•  Formulate  a  generic  methodology  for 
developing  technical  architectures  aimed  at 
improving  interoperation  of  weapon  and  C4I 
systems 


*  Explore  how  to  extend  the  technical 
architecture  concept  developed  for 
information  management  systems  to  weapon 
system  electronics 
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Case  Studies  of  Activities  Focused 
Mainly  on  Improving  Interoperation 


•  Army  Technical  Architecture  (AT A) 

•  Airborne  Reconnaissance  Information  Technical 
Architecture  (ARITA) 

•  Joint  Technical  Architecture  (JTA)  and  C4ISR 
Architectural  Framework 


•  Technical  Architecture  for  Information  Management 
(TAFIM) 

•  National  Institute  for  Standards  and  Technology  (  NIST) 
Application  Portability  Profile  (APP) 
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Case  Study  Initial  Findings  for 
Improving  Interoperation 

•  C4I  work  has  focused  on  information 
management  systems 

•  Technical  architectures  for  information 
management  systems  have  focused  mainly 
on  software  for  a  domain 

-  Do  not  address  domain’s  architectural  style 

-  Do  not  address  hardware 

-  Do  not  address  implementation  issues 

»  Institutional  arrangements 
»  Financial  aspects 
»  Scheduling  matters 

-  Such  factors  must  be  addressed  to  complete  the 
implementation  of  change 
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NDRI 


Prospective  Method  for  Improving 

Interoperation 


*  Research  of  relevant  experience 

-  Overview  of  the  interoperation  problem 

-  Case  studies  of  relevant  experiences 

-  Experience  of  the  ATA 

-  Experience  of  the  JTA 

*  Prospective  technical  architecture 

•  The  JTA  business  process  model 

•  Adapting  the  business  process  model 
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Development  of  the  Army  Technical 
Architecture  for  Information  Systems 

*  Goals:  improve  interoperation  among  information 
systems,  increase  reuse  of  their  software,  and 
broaden  commercial  standards  for  military  use 

*  Approach:  standardize  5  information-system  areas 

-  Information  processing 

-  Information  transfer 

-  Information  modeling  and  data  exchange 

-  Human  computer  interfaces 

-  Information  systems  security 

*  Method: 

-  Divide  5  areas  into  subareas  to  form  a  framework 

-  Define  functional  services  and  interfaces  for  each  subarea 

_ and  select  standards  (preferably _ 
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Implementation  of  the  Army 
Technical  Architecture  (ATA) 

•  Army  Acquisition  Executive 

-  Serves  as  the  ATA  Technical  Architect 

-  Supports  enforcement  of  the  use  of  the  ATA 

•  Army  System  Engineer/System  Engineering  Office 

-  Reports  to  the  ATA  Technical  Architect 

-  Formed  group  to  reach  consensus  on  ATA 
categories/sub-categories  and  their  standards 

-  Formed  Configuration  Control  Board,  processes  and 
schedules  to  maintain,  mature,  and  evolve  the  ATA 

-  Makes  ATA  compatible  and  consistent  with  JTA  and 
enforces  use  of  ATA 

-  Oversees  implementation  of  ATA  by  requiring  system 
migration  and  transition  plans 
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NDRI 


Prospective  Method  for  Improving 

Interoperation 


•  Research  of  relevant  experience 

-  Overview  of  the  interoperation  problem 

-  Case  studies  of  relevant  experiences 

-  Experience  of  the  AT A _ 

-  Experience  of  the  JTA _ J 

•  Prospective  technical  architecture 

•  The  JTA  business  process  model 

•  Adapting  the  business  process  model 
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Goals  for  Developing  the  Joint 
Technical  Architecture  (JTA)  for  C4I 

•  Provide  interoperability  among  all  tactical, 
strategic  and  sustaining  base  systems  that 
produce,  use  or  exchange  information 
electronically 

•  Mandate  standards  and  guidelines  to  reduce 
system  cost,  development  and  fielding  time 
while  minimizing  impact  on  performance 
wherever  possible 

•  Influence  direction  of  information  industry's 
standards-based  products 

•  Communicate  DoD's  intent  to  use  open  systems 
products  and  implementations  to  industry 


Volume  3.  Method.  FEB  1997 


Volume  3.  Method.  FEB  1997 


126  printed  01/27/2000  12:14 


Development  of  the  Joint  Technical 

Architecture  for  C4I 

NDRI 


•  DISA  sponsored  activity  to  achieve  JTA 
Version  1.0  in  six  months 

•  Used  ATA  as  the  starting  point  with  strong 
Service/Agency  participation  that  exploited 
work  and  results  of  many  other  ongoing 
related  technical  efforts  within  the  DoD 

•  Used  consensus  building  technique  to 
decide  on  standards  with  established  rules 
for  resolving  conflicts 
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JTA  Standards'  Selection  Criteria 

(1  of  2) 


JTA  standards  are  mandated  only  if  they  meet  the 
following  criteria: 

•  Interoperability  and/or  business  case: 

-  Ensures  joint  Service/Agency  information 
exchange 

-Supports  joint  (and  potentially  combined)  C4I 
operations 

-And/or  provides  strong  economic  justification 

»  Absence  of  a  mandated  standard  will  result  in 
increased  life-cycle  costs 
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JTA  Standards'  Selection  Criteria 

(2  of  2) 


•  Maturity:  They  are  technically  mature  and 
stable 

•  Implementability:  They  are  technically 
implementable 

•  Public:  They  are  publicly  available  (e.g.,  open 
systems  standards) 

•  Consistent  with  Authoritative  Sources:  They 
are  consistent  with  law,  regulation,  policy, 
and  guidance  documents 
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NDRI 


JTA  Implementation,  Evolution  and 
Configuration  Management 


•  Implementation  guidance  was  provided  in  an 
August  1996  DoD  Memorandum 

Acquisition  Executives  are  responsible 
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Prospective  Method  for  Improving 

Interoperation 

*  Research  of  relevant  experience 

*  Prospective  technical  architecture 

*  The  JTA  business  process  model 

*  Adapting  the  business  process  model 
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Scope  of  Activities  Addressed 
by  the  Technical  architecture 

*  Addresses  interoperation  at  the  force  and 
mission  level 

-At  force  level:  between  weapon  system(s) 
and  C4I  system(s) 

-At  mission  level:  between  weapon  systems 

*  Supports 

-  Platform  operation 

-Weapon  system  lethality  and 
countermeasure  functions 

-  Payload  functions 
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Develop  a  Technical  Architecture  for 
Improving  Interoperation  (1  of  2) 

1.  *  Identify  information-interchange  requirements 

for  the  domain’s  As-ls  state 

2.  *  Identify  information-interchange  requirements 

for  the  domain’s  To-Be  states 

3.  •  Combine  information-interchange  requirements 

for  domain’s  As-ls  and  To-Be  states 

4.  •  Select/develop  interface  standards  for 

information-interchange  requirements 

5.  •  Reconcile  selected  standards  with  the  JTA  for 

C4I  information  management  systems 
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Develop  a  Technical  Architecture  for 
Improving  Interoperation  (2  of  2) 

For  the  domain’s  To-Be  states 

g  •  Develop  equipment  migration  plans  to  satisfy 
requirements 

7.  •  Modify  weapon  system  program  management 

plans  to  include  migration  plans 

8.  *  Modify  weapon  system  budget  plans  to  reflect 

migration  plans 

9.  •  Reconcile  weapon  system  management  and 

budget  plans  to  assure  synchronized 
migration 

10.  •  Update  the  technical  architecture  to  reflect 

migration  plans  and  cooperative  efforts 
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1.  Define  information  interchange 
requirements  for  Domain’s  As-ls  State 

For  the  domain’s  As-ls  state 

1.1  •  Construct  the  operational  architecture 

1.2  *  Construct  the  system  architecture 

1.3  *  Define  the  information  interchange 

requirements 

1.4  .  Develop  a  list  of  information  interchange 

requirements 


Volume  3.  Method.  FEB  1997 


Volume  3.  Method.  FEB  1997 


135  printed  01/27/2000  12:14 


1.1  Construct  the  Operational 
Architecture  for  Domain’s  As-ls  State 

•  Inputs 

-  Domain  specific 

-  Warfighters 

-  Other  weapon  system  specific  inputs 

•  Products 

-  Operational  architecture  for  each  weapon  system’s  As- 
ls  state 

-  Operational  architecture  for  domain’s  As-ls  state 

-  Documentation  of  As-ls  operational  architecture  detail 

•  Verification  of  domain  As-ls  operational 
architecture  product  information 
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1.2  Construct  the  System  Architecture 
for  Domain’s  As-ls  State 


•  Inputs 

-  Domain  specific 

-  Service/Agency/warfighter  inputs 

-  Weapon  system  specific  inputs 

•  Products 

-  Weapon  system  As-ls  System  Architecture  for  each 
weapon  system  in  domain 

-  Domain  As-ls  System  Architecture  (system  architecture) 

-  Documentation  of  As-ls  system  architecture  detail  for 
domain 

•  Verification  of  As-ls  system  architecture  domain 
product  information 
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1.3  Define  the  information  interchange 
requirements  for  Domain’s  As-ls  State 


•  Inputs 

-  Operational  architecture  for  domain’s  As-ls  state 

-  System  architecture  for  domain’s  As-ls  state 

•  Method:  for  each  weapon  system  in  the 
domain 

-  Examine  every  link  between  the  weapon  system  and 
other  weapon  systems  and  C4I  systems 

-  Define  each  information  interchange 

•  Output 

-  Consolidated  statement  of  the  information 
interchange  requirements  for  the  domain’s  As-ls 
state 
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1.4  Categorize  the  Information- 
Interchange  Requirements 

Classify  the  information  interchange  requirements 
into  the  categories  used  in  the  JTA  (if  appropriate) 

-  Categories  of  main  interest  will  be:  Data  Interchange, 
Information  Standards  (covers  tactical  message  system 
systems),  Communications,  Operating  System  Services 

For  information  interchange  requirements  not 
classified  in  terms  of  JTA  categories 

-  Review  domain  technical  architectures  for  weapon  system 
electronics  for  appropriate  category  and  use  if  found 

-  If  not  found,  define  new  category 

Product:  matrix  of  categories  and  information 
interchange  requirements  that  fall  in  the  categories 
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2.  Define  information  interchange 
requirements  for  Domain’s  To-Be  States 

For  the  domain’s  To-Be  states 

2.1  *  Construct  the  operational  architecture 

2.2  *  Construct  the  system  architecture 

2.3  *  Define  the  information-interchange 

requirements 

2.4  .  Categorize  the  information-interchange 

requirements 
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2.1  Construct  the  Operational 
Architectures  for  Domain’s  To-Be  States 

•  Inputs 

-  Domain  specific 

-  Warfighters 

-  Other  weapon  system  specific  inputs 

•  Products 

-  Operational  architectures  for  weapon  system’s  To-Be  states 

-  Operational  architectures  for  domain’s  To-Be  states 

-  Documentation  of  system  architectures  for  domain’s  To-Be 
states 

•  Verification  of  To-Be  operational  architecture  product 
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2.2  Construct  the  System  Architectures 
for  Domain’s  To-Be  States 

•  Inputs 

-  Domain  specific 

-  Service/Agency/warfighter  inputs 

-  Weapon  system  specific  inputs 

•  Products 

-  Weapon  system  To-Be  system  architecture  for  each 
weapon  system  in  domain 

-  Domain  To-Be  system  architecture  (system  architecture) 

-  Documentation  of  To-Be  system  architecture  for  domain 

•  Verification  of  To-Be  system  architecture  product 
information  for  domain 
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2.3  Define  the  information  interchange 
requirements  for  Domain’s  To-Be  States 


•  Inputs 

-  Operational  architecture  for  domain’s  As-ls  state 

-  System  architecture  for  domain’s  As-ls  state 

•  Method:  for  each  weapon  system  in  the 
domain 

-  Examine  every  link  between  the  weapon  system  and 
other  weapon  systems  and  C4I  systems 

-  Define  each  information  interchange 

•  Output 

-  Consolidated  statement  of  the  information 
interchange  requirements  for  the  domain’s  As-ls 
state 
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2.4  Categorize  the  Information- 
Interchange  Requirements 

Classify  the  information  interchange  requirements 
into  the  categories  used  in  the  JTA  (if  appropriate) 

-  Categories  of  interest:  Data  Interchange,  Information 
Standards  (covers  tactical  message  system  systems), 
Communications,  Operating  System  Services 

For  information  interchange  requirements  not 
classified  in  terms  of  JTA  categories 

-  Review  all  weapon  system  Domain  TAs  for  appropriate 
category  and  use  if  found 

-  If  not  found,  define  new  category 

Product:  matrix  of  categories  and  information 
interchange  requirements  that  fall  in  the  categories 
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3.  Combine  information  interchange 
requirements  for  Domain’s  States 


*  Combine  the  As-ls  and  To-Be  information 
interchange  requirements  into  one  matrix  of 
requirements 
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4.  Select/Develop  Interface  Standards  for 
information  interchange  requirements 

4.1  *  Set  up  technical  architecture  using  categories  in 

the  JTA  and  a  new  hardware  interface  category 

4.2  *  Lookup  information  interchange  requirements  in 

all  relevant,  existing  TAs  for  relevant  rules  and 
standards  and  enter  those  in  the  respective  area 
of  the  domain  technical  architecture 

4.3  •  Handle  information  interchange  requirements  for 

which  rules  and  standards  cannot  be  found  in 
existing  TAs 

4-4  .  Assess  benefits  and  costs  of  adopting  each 
standard 

4.5  •  Adopt  most  worth  while  standards 
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4.3  Handle  Cases  for  Which  Rules  and 
Standards  Cannot  be  Found  in  Existing  TAs 

•  Information  interchange  requirements  for  which 
rules  and  standards  cannot  be  found: 

-a.  New  information  interchange  requirement  for 
which  there  are  existing  or  emerging 
commercial  standards  that  do  not  appear  in 
existing  TAs 

-b.  New  information  interchange  requirement 
covered  by  emerging  JTA  or  other  domain 
technical  architectures  standard 

-c.  New  information  interchange  requirement  for 
which  there  are  no  existing  or  emerging 
commercial  standards  that  do  not  appear  in  the 
existing  TAs 
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5.  Reconcile  the  Domain’s 
Standards  with  the  JTA 


•  Information  processing 

•  Information  transfer 

•  Information  modeling  and  information 

•  Human-computer  interfaces 

•  Information  systems  security 
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Develop  a  Technical  Architecture  for 
Improving  Interoperation  (2  of  2) 

_ For  the  domain’s  To-Be  states _ 

g  •  Develop  equipment  migration  plans  to  satisfy 
requirements _ 

7.  •  Modify  weapon  system  program  management 

plans  to  include  migration  plans 

8.  *  Modify  weapon  system  budget  plans  to  reflect 

migration  plans 

9.  •  Reconcile  weapon  system  management  and 

budget  plans  to  assure  synchronized 
migration 

10.  •  Update  the  technical  architecture  to  reflect 

migration  plans  and  cooperative  efforts 


Volume  3.  Method.  FEB  1997 


Volume  3.  Method.  FEB  1997 


149  printed  01/27/2000  12:14 


6.  Develop  Equipment  Migration 
Plans  to  Satisfy  Requirements 


6.1  *  Define  equipment  (HW  and  SW) 

replacement/modification  requirements 

6.2  *  Identify  the  worthwhile  opportunities  for  reuse 

6.2.1  -  Find  reuse  opportunities  by  analyzing  information 

interchanges 

6.2.2  -  Find  reuse  opportunities  by  examining  communications 

interfaces 

6.2.3  -  Analyze  the  costs  and  benefits  of  pursuing  reuse 

opportunities 

6.3  *  Develop  and  implement  a  program  for  reuse 

-  Use  section  8  of  the  methodology 

6.4  •  Develop  a  comprehensive  migration  plan  for  the 

domain’s  To-Be  states 
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6.2.1  Find  Reuse  Opportunities  by 
Analyzing  Information-Interchanges 

Things  to  look  for: 

•  Weapon  system  sending  or  receiving  same  or  similar 
information  to  other  external  systems 

•  Weapon  system  domain  system  architecture  indicating 
multiple  weapon  systems  in  domain  sending  same/similar 
information  to  other  systems 

•  Domain  system  Architecture  indicating  multiple  weapon 
systems  in  domain  receiving  same/similar  information  from 
other  systems 

•  Domain  weapon  systems  interchanging  data  with  other 
systems  using  the  same  message  systems,  investigate 
possibility  for  commonality  of  message  system  software 
and/or  communications  hardware 
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6.2.2  Find  Reuse  Opportunities  by 
Examining  Communications  Interfaces 


•  Software  reuse  possibilities  for  military 
message  system  systems 

-  Common  message  system  processing  software  for 
composing  message  systems  to  send  and  parsing 
received  message  systems  (part  of  Dll/COE 
common  applications) 

-  Extension  of  commonality  by  using  data  standards 
and  a  standards-based  database  across  all  systems 
using  military  message  system  systems 


*  Reuse  of  common  hardware 
devices/interfaces  for  communications 
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7.  Modify  Weapon  System  Program  Man¬ 
agement  Plans  to  Include  Migration  Plans 

*  Input:  migration  plans  for  domain’s  To-Be  states 
with  required  dates  for 

-  Initial  operational  capability  (IOC) 

-  Full  fielding  of  operational  capability 

*  Method:  weapon  system  program  managers 

-  Modify  program  management  plans 

-  Incorporate  sufficient  provisions  for  research,  development, 
test  and  evaluation,  and  production/modification  to  meet 
requirements  of  domain’s  To-Be  states 

-  Secure  approval  of  Service/agency  acquisition  executive 

*  Output:  Service/agency  approved 

-  Weapon  system  program  management  plans 
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8.  Modify  Weapon  System  Budget 
Plans  to  Reflect  Migration  Plans 

•  Input:  Service/agency  approved  program 
management  plans 

•  Method:  Weapon  system  program  managers 

-  Estimate  funding  requirements  to  support  the 
migration  plans  for  the  domain’s  To-Be  states 

-  Modify  program  budget 

-  Modify  program  inputs  to  the  POM  and  PPBS 

-  Secure  support  for  modified  budget 

»  Weapon  system’s  using  command 
»  Service/agency  deputy  chief  of  staff  for  operations 
»  Combatant  CINCs  and  Joint  Staff 
»  Service/agency  acquisition  executive 

•  Output:  Service/agency  approved  funding 

_ -  Planned,  programmed,  and  budgeted _ 
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9.  Reconcile  Weapon  System  Management 
and  Budget  Plans  with  Joint  Migration 

*  Input:  for  each  weapon  system  in  the  domain 

-  Program  management  plan 

-  Service/agency  approved  budget  plans 

*  Method:  Domain  Technical  Architecture  Committee 

-  Assesses  ability  of  program  management  plans  and 
program  budgets  to  support  migration  plans  for 
domain’s  To-Be  states 

-  Identifies  inconsistencies  and  risks 

-  Identifies  preferred  and  alternate  corrective  actions 

*  Output:  identification  of  implementation  issues 

-  Nature  and  implications 

-  Options  for  adjusting  migration/program  plans 


Volume  3.  Method.  FEB  1997 


Volume  3.  Method.  FEB  1997 


155  printed  01/27/2000  12:14 


10.  Update  Technical  Architecture  to 
Reflect  Migration  Plans  and  Joint  Efforts 


*  Input:  reconciliation  of  weapon  system 
program  and  budget  plans 

*  Method:  Domain  Technical  Architecture  Committee 

-  Updates  the  resource  and  schedule  sections  of  the 
technical  architecture 

-  As  necessary,  revises 

»  Economic  analyses 

»  Domain’s  To-Be  states  to  reflect  funding  and  schedule 
constraints 

»  Technical  section  of  the  technical  architecture 

*  Output:  Revised  technical  architecture 

-  Reflects  current  knowledge  of  fiscal  and  schedule 
constraints 
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Prospective  Method  for  Improving 

Interoperation 

*  Research  of  relevant  experience 

*  Prospective  technical  architecture 

*  The  JTA  business  process  model 

*  Adapting  the  business  process  model 
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JTA  Business  Process  Model 


*  Assign  institutional  authority  and  responsibility  at 
high  level  in  organization 

*  Establish  well  defined  objectives 

*  Establish  well  defined  criteria  for  mandating 
standards 

*  Establish  well  organized  JTA  development  working 
group  with  representatives  from  all  relevant 
organizations  that  can  tap  their  organization  SMEs 
and  represent  their  organization's  position 

*  Institutionalize  policies  and  procedures  for  JTA 
implementation,  enforcement,  evolution  and 
configuration  management 
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Prospective  Method  for  Improving 

Interoperation 

*  Research  of  relevant  experience 

*  Prospective  technical  architecture 

*  The  JTA  business  process  model 

*  Adapting  the  business  process  model 
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Adapting  the  JTA  Business 
Process  Model 

Domain  technical  architecture 

•  High  level  institutional  authorities:  extend  to 
include  domain  managers 

•  Objectives  and  standards  selection  criteria:  no 
change  from  JTA 

•  Categories:  expand  on  JTA  categories  to  include 
hardware  interfaces 

•  Domain  working  group:  different  process  from  JTA 

•  Implementation,  enforcement,  evolution,  and 
configuration  management:  include  role  of  domain 
manager 
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JTA  Related  Issues  (1  of  2) 


*  Lack  of  warfighter  guidance  as  to  how  the  U.S.  plans 
to  fight  in  the  future  (the  To-Be  Operational 
Architecture) 

-Impedes  intelligent  choice  in  supporting  emerging 
technologies,  standards,  etc. 

-  Impedes  cost  benefit  trade  offs  for  system 
migrations  to  JTA  standards,  especially  emerging 
standards 

*  Lack  of  synchronization  of  migration  plans  across 
Services/agencies  could 

-  Negatively  affect  Joint  Task  Force  operations 

-  Inefficiently  apply  DoD  funds 
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JTA  Related  Issues  (2  of  2) 


NDRI 


•  Need  more  research  on  how  to  evolve 
warfighting  systems  as  standards  evolve: 
ability  to  maximize  use  of  new  technology 
while  minimizing  mismatches  due  to 
asynchronous  implementations 

•  Dll/COE 

-  Based  on  specific  hardware  platforms  and 
software  systems 

-  Lack  of  attention  to  evolutionary  change 

•  Need  to  research  how  to  integrate  the 
multitude  of  stove-piped  DoD  message 
system  systems 
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Sections  of  the  Methodology 


1.  Forming  the  technical  architecture  concept 

2.  Dividing  electronics  into  domains 

3.  Setting  the  role  of  a  domain’s  technical  architecture 

4.  Structuring  a  domain’s  technical  architecture 

5.  Reducing  military  specifications 

6.  Reusing  hardware  and  software 

7.  Interoperating  weapon  and  C4I  systems 

8.  Coordinating  TAs  across  Services/agencies 

9.  Integrating  TAs  across  domains 
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Technical  Support  Contractors  Assist  the 
Services  and  Defense  Agencies 

Services  and  Defense  Agencies  and  their 
Domain  Technical  Architecture  Committees 


ARINC-like 


services  for 
each  domain 

Domain  Technical  Support  Contractors 
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An  Interoperability  FFRDC  Also 
Assists  the  Services  and  Agencies 

Services  and  Defense  Agencies 


Assistance  in 
securing  and 
evaluating 
domain 
technical 
support 
contractors 


Defense  Systems  Interoperability  FFRDC 


Definition  of 
domains  and 
subdomains 


Refinement  of 
methods  for 
developing 
technical 
architectures 
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Coordinating  Technical  Architectures 
Across  Services/Agencies 


•  Option  1 ,  bottom-up 


•  Option  2,  top  down 
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Option  1,  Bottom-Up  Coordination  of 
TAs  Across  Services  and  Agencies 

•  For  each  domain/subdomain,  establish  a 

mechanism  for  bottom-up  governance 

-  Designate  a  lead  service 

-  Form  a  Domain  Technical  Architecture  Committee 
with  a  strong  leader 

•  Motivate  the  DTAC 

-  Hold  service/agency  acquisition  executives 
responsible  for  building  and  using  TAs 

-  Provide  acquisition  executives  authority  to  task 
their  service/agency  acquisition  organizations 

•  Provide  tecnical  support  at  each  level 

-  FFRDC  support  to  acquisition  executives 

-  ARINC-like  support  to  each  domain 
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Coordinating  Technical  Architectures 
Across  Services/Agencies 


•  Option  1 ,  bottom-up 


•  Option  2,  top  down 
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Option  2,  Top-Down  Concept  for 
Integrating  Across  Services  and  Agencies 

*  Establish  a  mechanism  for  top-level  guidance 

-  Form  a  Defense  Systems  Interoperability  Board 
(DSIB)  with  OSD  members  only 

-  Form  a  Defense  Systems  Interoperability  Council 
that  includes  industry 

*  Empower  the  DSIB 

-  Distribution  of  interoperability  funds 

-  Review  of  domain  technical  architectures 

-  Role  in  milestone  decisions  for  acquisition 
programs 

*  Provide  technical  support  at  each  level 

-  FFRDC  support  to  DSIB,  services  and  agencies 

-  ARINC-like  support  to  each  domain 
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Combatant  CINCs,  the  Joint  Staff, 
Congress,  and  Industry  Guide  the  DSIB 


NDRI 


Option  2< 
Only  ^ 


Combatant  CINCs  and  Joint  Staff 


Congress 


Defense  Systems 
Interoperability 
Council 

(includes  industry) 


Defense  Systems  Interoperability  Board 
(OSD  members  only) 


Assessments  of  interoperability  performance 
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The  DSIB  Guides  the  Services  and 

Defense  Agencies 


Defense 

systems 

interoperability 

goal 

-  Insert 
technology 

-  Reduce  cost 

-  Interoperate 


Domain 

definitions 


Priorities  for 
interoperability 
improvements 
by  domain 


Interoper¬ 

ability 

funds 


Services  and  Defense  Agencies 
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A  Federally  Funded  Research  and 
Development  Center  Assists  the  DSIB 


NDRI 


interoperability 

Analysis  of 

performance 

Technical 

weapon  system 

-  Time  to  insert  new 

review  of 

interoperability 

technology 

domain 

suitability 

-  Weapon  system 

technical 

for  each 

electronics  costs  architectures 

acquisition 

-  Joint  forces 

milestone 

performance 

review 

Defense  Systems  Interoperability  FFRDC 
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Sections  of  the  Methodology 


1.  Forming  the  technical  architecture  concept 

2.  Dividing  electronics  into  domains 

3.  Setting  the  role  of  a  domain’s  technical  architecture 

4.  Structuring  a  domain’s  technical  architecture 

5.  Reducing  military  specifications 

6.  Reusing  hardware  and  software 

7.  Interoperating  weapon  and  C4I  systems 

8.  Coordinating  TAs  across  services/agencies 

9.  Integrating  TAs  across  domains 
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An  Interoperability  FFRDC  Could 
Facilitate  Integration  Across  Domains 

Services  and  Defense  Agencies 


Identification  of 
opportunities 
for  integration 


of  technical 
architecture 
efforts  across 
domains 

Defense  Systems  Interoperability  FFRDC 
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Outline 


NDRI 

I.  Introduction 

II.  Methodology 

III.  Pilot  test 

IV.  Conclusions 

V.  Next  steps 
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Phases  of  the  Pilot  Test 


NDRI 


Phase  I: 
Phase  II: 
Phase  III: 
Phase  IV: 


Prepare  a  plan  for  the  test 

Execute  the  plan 

Analyze  the  pilot  test  results 

Refine  the  method  for  developing 
technical  architectures 
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Phase  I:  Prepare  a  Plan  for  the  Test 


A.  Develop  support  for  concept  of  a  pilot  test 

-  OSD,  A&T  and  C3I 

-  Service  and  defense  agency  acquisition  executives 

B.  Develop  a  specific  concept  for  the  pilot  test 

-  Test  objectives  and  extent  of  the  test 

-  Domain  for  the  pilot  test:  participating  weapon 
system  programs 

C.  Develop  the  test  plan  with  the  participants 

-  Roles,  activities,  and  milestones 

-  Memoranda  of  agreement  for  participants 

D.  Arrange  for  test  support 

-  Inputs  from  other  organizations  (CINCs,  Joint  Staff) 

_ -  Funding,  and  contractor  support _ 
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Phase  II:  Execute  the  Test  Plan 


NDRI 

Proposed  participants  for  the  pilot  test 


*  Organizations  involved  in  the  development  of 
the  technical  architecture 


*  Organizations  invovled  in  providing  guidance 
for  the  development  of  the  technical 
architecture 


*  Organizations  involved  in  facilitating  the  test 
and  evaluating  the  outcome 


Volume  3.  Method.  FEB  1997 


Volume  3.  Method.  FEB  1997 


180  printed  01/27/2000  12:14 


Proposed  Participants  for  the  Pilot  Test 


*  Development  of  the  technical  architecture 

-  Domain  Technical  Architecture  Committee 

-  Participating  acquisition  programs 

-  Service  acquisition  organizations 

-  Domain  Technical  Support  Contractors _ 

*  Guidance  (Option  2,  only) 

-  Defense  Systems  Interoperability  Board 

-  Combatant  CINCs  and  Joint  Staff 

-  Defense  Systems  Interoperability  Council 

*  Facilitation  and  evaluation 

-  Undersecretary  for  Acquisition  and  Technology 

-  Participating  services  and  defense  agencies 

-  Joint  Test  Team  and  Interoperability  FFRDCs 
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Domain  Technical  Architecture  Committee 
(Role  During  Pilot  Test,  1  of  3) 

•  Review  and  provide  comments  on 

-  Draft  report:  Strategy  for  Improving  Interoperability 
of  Weapon  System  Electronics 

-  Draft  test  plan 

•  Assimilate  guidance  from  the  Defense 
Systems  Interoperability  Board  (Option  2  only) 

-  Domain’s  interoperability  improvement  priorities 

•  Use  improvement  priorities  to 

-  Select  tactics  needing  improvement 

»  Reduce  Mil  Specs 
»  Increase  reuse 
»  Improve  interoperation 

-  Focus  technical  architecture  development  effort 
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Domain  Technical  Architecture  Committee 
(Role  During  Pilot  Test,  2  of  3) 

•  Tailor  the  technical  architecture  development 
methodology  to  suit  the  domain’s  priorities 

•  Develop  the  technical  and  business  concepts 
for  improving  interoperability 

-  Design  alternative  approaches 

-  Conduct  tradeoff  studies 

»  Consider  As-ls  case  and  alternatives 

»  Consider  affects  on  the  life-cycle  costs  for  the 
weapon  systems  in  the  domain 

»  Examine  influence  on  DoD’s  total  cost 

-  Select  a  preferred  concept 

-  Obtain  approval  of  the  participating  services  and 
agencies  for  the  preferred  concept 
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Domain  Technical  Architecture  Committee 
(Role  During  Pilot  Test,  3  of  3) 


•  Develop  the  technical  and  business  approach 

-  Work  with  domain  members  and  the  Domain 
Technical  Support  Contractor 

-  Secure  approval  of  the  participating  services  and 
agencies  for  the  improvement  approach 

•  Complete  the  technical  architecture  document 

-  Obtain  independent  reviews  (technical  and  business) 

-  Submit  to  the  Defense  Systems  Interoperability  Board 
for  approval  (Option  2  only) 

•  Evaluate  test  results  and  recommend  changes 
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Participating  Acquisition  Programs 
(Role  During  Pilot  Test) 

•  Review  and  provide  comments  on 

-  Draft  report:  Strategy  for  Improving  Interoperability  of 
Weapon  System  Electronics 

-  Draft  test  plan 

•  Assist  A&T  in  defining  test  scope 

-  Test  objectives  and  extent  of  the  test 

-  Domain  for  the  pilot  test:  participating  weapon  system 
programs 

•  Assign  acquisition  staff  to 

-  Domain  Technical  Architecture  Committee 

•  Improve  weapon  system  development  program 

-  Domain  technical  architecture  provides  improvement 

•  Evaluate  test  results  and  recommend  changes 
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Service  Acquisition  Organizations 
(Role  During  Pilot  Test,  1  of  2) 

*  Review  and  provide  comments  on 

-  Draft  report:  Strategy  for  Improving  Interoperability  of 
Weapon  System  Electronics 

-  Draft  test  plan 

*  Assist  A&T  in  defining  test  scope 

-  Test  objectives  and  extent  of  the  test 

-  Domain  for  the  pilot  test,  type(s)  of  equipment,  and 
participating  programs 

*  Assign  staff  to 

-  Domain  Technical  Architecture  Committee 

-  Joint  test  team 

*  Select  a  chair  for  the  Domain  Technical 
Architecture  Committee 
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NDRI 


Service  Acquisition  Organizations 
(Role  During  Pilot  Test,  2  of  2) 


•  Review  progress  of  the  Domain  Technical 
Architecture  Committee 

•  Review  and  approve  the  technical  architecture 
that  is  developed 

•  Commit  the  service/agency  to  supporting  and 
applying  the  technical  architecture 

•  Use  the  domain  technical  architecture  in 
reviewing  the  domain’s  acquisition  programs 

•  Evaluate  test  results  and  recommend  changes 
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Domain  Technical  Support  Contractors 

(Role  During  Pilot  Test) 

•  Review  and  provide  comments  on 

-  Draft  report:  Strategy  for  Improving  Interoperability 
of  Weapon  System  Electronics 

-  Draft  test  plan 

•  Assign  staff  to 

-  Domain  Technical  Architecture  Committee 

-  Joint  Test  Team 

•  Facilitate  the  work  of  the  Domain  Technical 
Architecture  Committee 

-  Perform  analyses  and  tradeoff  studies 

-  Facilitate  meetings 

-  Draft  materiel  for  the  technical  architecture 

-  Prepare  the  technical  architecture  document 
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Proposed  Participants  for  the  Pilot  Test 

*  Development  of  the  technical  architecture 

-  Domain  Technical  Architecture  Committee 

-  Particpating  acquisition  programs 

-  Service  acquisition  organizations 

-  Domain  Technical  Support  Contractors _ 

*  Guidance  (Option  2,  only) 

-  Defense  Systems  Interoperability  Board 

-  Combatant  CINCs  and  Joint  Staff 

-  Defense  Systems  Interoperability  Council _ 

*  Facilitation  and  evaluation 

-  Undersecretary  for  Acquisition  and  Technology 

-  Participating  services  and  defense  agencies 

-  Joint  Test  Team  and  Interoperability  FFRDCs 
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Option  2 

L-,OnlV  r- 


Defense  Systems  Interoperability 
Board  (Role  During  Pilot  Test) 


•  For  weapon  systems  in  the  test  domains 

-  Provide  assessments  of  interoperability  performance 
to  Combatant  CINCs  and  Joint  Staff 

-  Analyze  CINC  and  Joint  Staff  feedback  about 
prioritized  needs  for  improved  interoperability 

•  Provide  improvement  priorities  to  Domain 
Technical  Architecture  Committees 

•  For  each  test  domain,  review  the  domain’s 

-  Test  progress  and  technical  architecture 

-  Acquisition  programs 

•  Provide  inputs  to  acquisition  milestone  reviews 

-  Assessment  of  interoperability  suitability 

•  Evaluate  test  results  and  recommend  changes 
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Option  2 
■  NDRI  ■ 


Combatant  CINCs  and  Joint  Staff 
(Roles  During  Pilot  Test) 


•  Review  and  provide  comments  on 

-  Draft  report:  Strategy  for  Improving  Interoperability 
of  Weapon  System  Electronics 

-  Draft  test  plan 

•  For  weapon  systems  in  the  test  domains: 

-  Review  assessment  of  interoperability 
performance  provided  by  the  acting  DSIB 

-  Prioritize  needs  for  improved 
interoperability 

-Share  priorities  with  the  acting  DSIB 

•  Evaluate  test  results  and  recommend 
improvements  to  the  methodology 
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Defense  Systems  Interoperability 
Council  (Role  During  Pilot  Test) 


•  Review  and  provide  comments  on 

-  Draft  report:  Strategy  for  Improving  Interoperability  of 
Weapon  System  Electronics 

-  Draft  test  plan 


•  For  weapon  systems  in  the  test  domain 

-  Analyze 

»  DSIB’s  assessment  of  interoperability  performance 

»  CINC  and  Joint  Staff  prioritized  needs  for  improved 
interoperability 

»  Actions  that  industry  could  assist  or  take 

-  Make  recommendations  to  the  DSIB 


•  Evaluate  test  results  and  recommend  changes 
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Proposed  Participants  for  the  Pilot  Test 

*  Development  of  the  technical  architecture 

-  Domain  Technical  Architecture  Committee 

-  Particpating  acquisition  programs 

-  Service  acquisition  organizations 

-  Domain  Technical  Support  Contractors 

*  Guidance  (Option  2,  only) 

-  Defense  Systems  Interoperability  Board 

-  Combatant  CINCs  and  Joint  Staff 

-  Defense  Systems  Interoperability  Council _ 

*  Facilitation  and  evaluation 

-  Undersecretary  for  Acquisition  and  Technology 

-  Participating  services  and  defense  agencies 

-  Joint  Test  Team  and  Interoperability  FFRDCs 
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Undersecretary  for  Acquisition  and 
Technology  (Roles  During  Pilot  Test) 

•  Approve  test  concept;  assign  test  director  &  staff 

•  Designate  boards/groups  to  serve  as  acting 

-  Defense  Systems  Interoperability  Board  (Option  2  only) 

-  Defense  Systems  Interoperability  Council  (Option  2  only) 

•  Secure  support  of  participating  organizations 

-  CINCs,  Joint  Staff  (Option  2  only) 

-  Service  acquisition  executives 

-  Acquisition  programs,  and  service  acquisition  orgs 

•  Review  and  approve  test  plan 

•  Arrange  for  test  support 

•  Review  test  progress 

•  Evaluate  test  results  &  expand  to  more  domains 
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Participating  Services  and  Defense 
Agencies  (Role  During  Pilot  Test) 

*  Review  and  provide  comments  on 

-  Draft  report:  Strategy  for  Improving  Interoperability  of 
Weapon  System  Electronics 

-  Draft  test  plan 

*  Assist  A&T  in  defining  test  scope 

-  Test  objectives  and  extent  of  the  test 

-  Domain  for  the  pilot  test:  participating  weapon  system 
programs 

*  Assign  acquisition  staff  to  the  joint  test  team 

*  For  each  test  domain,  review  the  domain’s 

-  Test  progress,  technical  architecture  and  acq.  pgms 

*  Evaluate  test  results  and  recommend  changes 
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NDRI 


Joint  Test  Team 
(Role  During  Pilot  Test) 


•  Review  and  provide  comments  on 

-  Draft  report:  Strategy  for  Improving  Interoperability 
of  Weapon  System  Electronics 

•  Assist  the  DTAC  in  preparing  the  test  plan 

•  Facilitate  execution  of  the  test  plan 

•  Monitor  progress  of  the  test 

-  Observe  performance  of  the  Domain  Technical 
Architecture  Committee 

•  Evaluate  test  results  and  recommend 
changes 
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Interoperability  FFRDCs 
(Role  During  Pilot  Test) 

•  Review  and  provide  comments  on 

-  Draft  report:  Strategy  for  Improving  Interoperability  of 
Weapon  System  Electronics 

-  Draft  test  plan 

•  Assign  staff  to  observe  and  assist 

-  Domain  Technical  Architecture  Committee 

-  Joint  Test  Team 

*  Facilitate  the  work  of  the  Defense  Systems 
Interoperability  Board 

-  Assess  interoperability  performance 

-  Evaluate  domain  technical  architectures 

*  Evaluate  test  results  and  recommend  changes 
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Conclusions 


*  Improving  interoperability 

-  Requires  up  front  investment 

-  Yields  downstream  dividends  for  warfighters 

*  Goal-oriented  focus,  such  as  improving 
interoperability,  would  provide 

-  Basis  for  communicating  needs,  conducting 
tradeoff  studies,  and  focusing  resources 

•  Extension  of  the  technical  architecture 
approach  to  weapon  systems 

-  Promising  concept,  a  method  is  available 

-  Requires  effort  and  cooperation 

•  Pilot  test  needed 
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Next  Steps 


NDRI 


•  OS-JTF  decisions 
-Suitability  of  methodology 

-  Readiness  of  methodology  for  a  pilot  test 

-  Domain  for  a  pilot  test 

•  USD  A&T  decision  to  support  a  pilot  test 

•  Preparation  for  a  pilot  test 

-  Funding  and  contractor  support  for  a  pilot 
test 
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Subsequent  Steps  of  the  Strategy 


NDRI 


Step  1 :  design  a  methodology  for  developing  a 
technical  architecture  for  a  domain  of  weapon 
system  electronics 

Step  2:  pilot  test  the  methodology 


Step  3:  extend  the  application  of  the 
methodology  to  additional  demonstrations 

Step  4:  implement  the  methodology  and 
integrate  the  technical  architectures  across 
services  and  domains 
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